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DETAILED ACTION 

1 . A request for continued examination under 37 CFR 1.114, including the fee set 
forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this 
application is eligible for continued examination under 37 CFR 1.1 14, and the fee set 
forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action 
has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on August 
30, 2006 has been entered. 

2. This is a Non-Final Office Action. 

3. Claims 1-15 have been examined, with claims 1, 6, 8, and 11 being the 

« 

independent claims. 

4. Claims 1-1 5 are objected to. 

5. Claims 1-15 are rejected. 

The Specification 

6. Applicant is reminded of the continuing requirement to update the status 
(pending, allowed, etc.) of all parent priority applications in the first line of the 
specification, when appropriate, and the status of all citations of U.S. filed applications 
in the specification should also be updated, when appropriate. 
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7. The specification is objected to as failing to provide proper antecedent basis for 
the claimed subject matter. See 37 CFR 1.75(d)(1) and MPEP § 608.01 (o). Correction 
of the following is required: The following terms are not defined in the specification" 

a) "field validation pattern;" 

b) "disposed in said markup;" 

c) "validation shell function;" 

d) "pattern validation routine;" and 

e) "pervasive device." 

If the Applicant believes these terms are defined in the specification, the Applicant 
should cite to specific paragraph and line numbers establishing those definitions. 

Claims Objections 

8. Claims 1-15 are objected to because of the following informalities: 

a) The claims specify the term "markup" which is a non-standard term and is not 
found to be specially defined in the specification. Upon review of the claims and 
specification, the Examiner believes the Applicant intended the term to mean "markup 
language program" and the term will be so read for the remainder of this Office Action. 

b) The term "validation script library" is defined in the specification by reference 
only, which is read by the Examiner, based on a review of the claims and specification, 
as a client side input validator, and will be so read for the remainder of this Office 
Action. 

Appropriate correction is required. 
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Claims Rejections - 35 U.S.C. 112, First Paragraph 
The following is a quotation of the first paragraph of 35 U.S.C. 112: 

The specification shall contain a written description of the invention, and of the manner and process of 
making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the 
art to which it pertains, or with which it is most nearly connected, to make and use the same and shall 
set forth the best mode contemplated by the inventor of carrying out his invention. 

9. Claims 1-15 are rejected under 35 U.S.C. 112, first paragraph, as failing to 
comply with the enablement requirement. The claim(s) contains subject matter which 
was not described in the specification in such a way as to enable one skilled in the art to 
which it pertains, or with which it is most nearly connected, to make and/or use the 
invention. 

a) The term "field validation pattern" is not defined in the specification. The 
closest term is "pattern validation" which refers to the inspection of user input to ensure 
that the input conforms to a particular pattern, such as date formats, time formats, 
telephone number formats, etc. See, disclosure, paragraph [0003]. Upon examination 
of the claims and the specification, it is the Examiner's belief that Applicant intended the 
term "filed validation pattern" to refer to "pattern validation" within the entry field of a 
form for purposes of checking input format for dates, time, telephone numbers, etc., and 
the term will be so read for the remainder of this Office Action. 

v 

b) The term "disposed in said markup" is not defined in the specification. It is the 
belief of the Examiner, based on a review of the claims and specification, that the 
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Applicant intended to the term to mean that the invention used a markup computer 
language, and the term will be so read for the remainder of this Office Action. 

c) The term "validation shell function" is not defined in the specification. The 
term "shell," as used in the software arts, was known to one of ordinary skill in the art as 
"a program that interprets sequences of text input as commands." See, "IEEE 100, The 
Authoritative Dictionary of IEEE Standards Terms," Seventh Edition, IEEE Press, 2000, 
definition of "shell." Accordingly, based on a review of the claims and specification, the 
term "validation shell function" is read as a user interface to enter the data into the form, 
which is read as inherent in a form filling and validation program, and the phrase will be 
so read for the remainder of this Office Action. 

d) The term "pattern validation routine" is not defined in the specification. Upon 
examination of the claims and the specification, it is the Examiner's belief that the 
Applicant intended the term to be the comparison of input with valid input patterns within 
the validation routine, and will be so read for the remainder of this Office Action. 

e) The term "pervasive device" is not defined in the specification. The Examiner 
consulted "IEEE 100, The Authoritative Dictionary of IEEE Standards Terms," Seventh 
Edition, IEEE Press, 2000, and "Microsoft Computer Dictionary," fifth edition, Microsoft 
Press, 2002, and the term was not found. The Examiner believes the term to have 
been intended by the Applicant to mean that the device is permanent, such as a 
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permanent client device. See, Claim 15. See also, "American Heritage College 
Dictionary, fourth edition, Houghton Mifflin Co., 2002, definition of "pervasive." The term 
will be so defined for the remainder of this Office Action. It is noted that the term 
"pervasive" as applied to a client device, is read as non-functional descriptive language. 
It was known to one of ordinary skill in the art at the time of the invention that any device 
connected to a server as a client is permanent while connected to the server. Upon 
disconnection, the device is no longer a client device, it is merely a stand-alone device. 
Therefore, the term "pervasive" is read as non-functional descriptive language that does 
not constitute a patentable distinction over the prior art. 

f) The term "validation script library" is defined in the specification by its use only, 
which is read by the Examiner, based on a review of the claims and specification, as a 
client side input validator, and will be so read for the remainder of this Office Action. 

10. In addition, Claim 15 is rejected under 35 U.S.C. 1 12, first paragraph, as failing 
to comply with the written description requirement. The claims contains subject matter 
which was not described in the specification in such a way as to reasonably convey to 
one skilled in the relevant art that the inventors, at the time the application was filed, 
had possession of the claimed invention, and is therefore new matter. The term 
"pervasive device" is not defined in the specification. The Examiner consulted "IEEE 
100, The Authoritative Dictionary of IEEE Standards Terms," Seventh Edition, IEEE 
Press, 2000, and "Microsoft Computer Dictionary," fifth edition, Microsoft Press, 2002, 
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and the term was not found. The Examiner believes the term to have been intended by 
the Applicant to mean that the device is permanent, such as a permanent client device. 
See, Claim 15. See also, "American Heritage College Dictionary, fourth edition, 
Houghton Mifflin Co., 2002, definition of "pervasive." The term will be so defined for the 
remainder of this Office Action. 

11. In the interest of compact prosecution, the application is further examined against 
the prior art, as stated below, upon the assumption that the applicants may overcome 
the above stated rejection under 35 U.S.C. 112, first paragraph. 

Claims Rejections - 35 U.S.C. 112, Second Paragraph 

The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

12. Claims 1-15 are rejected under 35 U.S.C. 112, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. Specifically, the claims are deficient in failing to 
particularly point out and distinctly claim the subject matter related to the following 
terms: 

a) The term "field validation pattern" is not defined in the specification. The 
closest term is "pattern validation" which refers to the inspection of user input to ensure 
that the input conforms to a particular pattern, such as date formats, time formats, 
telephone number formats, etc. See, disclosure, paragraph [0003]. Upon examination 
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of the claims and the specification, it is the Examiner's belief that Applicant intended the 
term "filed validation pattern" to refer to "pattern validation" within the entry field of a 
form for purposes of checking input format for dates, time, telephone numbers, etc., and 
the term will be so read for the remainder of this Office Action. 

b) The term "disposed within markup" is not defined in the specification. It is the 
belief of the Examiner, based on a review of the claims and specification, that the 
Applicant intended to the term to mean that the invention used a markup computer 
language, and the term will be so read for the remainder of this Office Action. 

c) The term "validation shell function" is not defined in the specification. The 
term "shell," as used in the software arts, was known to one of ordinary skill in the art as 
"a program that interprets sequences of text input as commands." See, "IEEE 100, The 
Authoritative Dictionary of IEEE Standards Terms," Seventh Edition, IEEE Press, 2000, 
definition of "shell." Accordingly, based on a review of the claims and specification, the 
term "validation shell function" is read as a user interface to enter the data into the form, 
which is read as inherent in a form filling and validation program, and the phrase will be 
so read for the remainder of this Office Action. 

d) The term "pattern validation routine" is not defined in the specification. Upon 
examination of the claims and the specification, it is the Examiner's belief that the 
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Applicant intended the term to be the comparison of input with valid input patterns within 
the validation routine, and will be so read for the remainder of this Office Action. 

e) The term "pervasive device" is not defined in the specification. The Examiner 
consulted "IEEE 100, The Authoritative Dictionary of IEEE Standards Terms," Seventh 
Edition, IEEE Press, 2000, and "Microsoft Computer Dictionary," fifth edition, Microsoft 
Press, 2002, and the term was not found. The Examiner believes the term to have 
been intended by the Applicant to mean that the device is permanent, such as a 
permanent client device. . See, Claim 15. See also, "American Heritage College 
Dictionary, fourth edition, Houghton Mifflin Co., 2002, definition of "pervasive." The term 
will be so defined for the remainder of this Office Action. It is noted that the term 
"pervasive" as applied to a client device, is read as non-functional descriptive language. 
It was known to one of ordinary skill in the art at the time of the invention that any device 
connected to a server as a client is permanent while connected to the server. Upon 
disconnection, the device is no longer a client device, it is merely a stand-alone device. 
Therefore, the term "pervasive" is read as non-functional descriptive language that does 
not constitute a patentable distinction over the prior art. 

f) The term "validation script library" is defined in the specification by its use only, 
which is read by the Examiner, based on a review of the claims and specification, as a 
client side input validator, and will be so read for the remainder of this Office Action. 
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13. Claims 1-15 are rejected under 35 U.S.C. 112, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. Specifically with regards to the term "markup." 

Where applicant acts as his or her own lexicographer to specifically define a term 
of a claim contrary to its ordinary meaning, the written description must clearly redefine 
the claim term and set forth the uncommon definition so as to put one reasonably skilled 
in the art on notice that the applicant intended to so redefine that claim term. Process 
Control Corp. v. HydReclaim Corp., 190 F.3d 1350, 1357, 52 USPQ2d 1029, 1033 (Fed. 
Cir. 1999). 

The term "markup" in claims 1-15 is used by the claim to mean something other 
than a document containing tracked changes the can be viewed or printed, or markup 
language software or document, while the accepted meaning is either a document 
containing tracked changes the can be viewed or printed, or markup language software 
or document. 

"Markup" is was known to one of ordinary skill in the art at the time of the 
invention to be defined as: "Comments and tracked changes such as insertions, 
deletions, and formatting changes that you can view, of print. See, "Microsoft Computer 
Dictionary," fifth edition, Microsoft Press, 2002, definition of "markup." This definition is 
inapplicable within the context of the use of the term in the claims. 

"Markup" was alternatively known to one of ordinary skill in the art at the time of 
the invention as: The collection of tags describing the specifications on an electronic 
document, as for formatting." See, "The American Heritage College Dictionary," fourth 
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edition, Houghton Mifflin, Co., 2002, definition of "markup." This definition is consistent 
with the Examiner's interpretation of the term "disposed in markup" as meaning use of a 
markup language, however, that interpretation was denied by Applicant. See, Remarks, 
page 8, noting that Applicant failed to state what the term was intended to mean. 

Applicant rejected the Examiner's broadest reasonable interpretation of the term 
which were consistent with accepted meanings that were known to one of ordinary skill 
in the art at the time of the invention, and has failed to define the term in the 
specification or to clarify the term in responses to Office Actions. Therefore, the term 
"markup" is indefinite because the specification does not clearly redefine the term. 

14. In the interest of compact prosecution, the application is further examined against 
the prior art, as stated below, upon the assumption that the applicants may overcome 
the above stated rejection under 35 U.S.C. 112, second paragraph. 

Claims Rejections - 35 U.S.C. 102 

The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 
A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by 
another filed in the United States before the invention by the applicant for patent or (2) a patent 
granted on an application for patent by another filed in the United States before the invention by the 
applicant for patent, except that an international application filed under the treaty defined in section 
351(a) shall have the effects for purposes of this subsection of an application filed in the United States 
only if the international application designated the United States and was published under Article 21(2) 
of such treaty in the English language. 
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Claims 1-15 are rejected under 35 U.S.C. 102(e) as being anticipated by Scholz, et al. 
(U.S. Patent Application Publication 2003/0078949, filed April 30, 2001 and published 
April 24, 2003) [hereinafter "Scholz"]. In general, it is noted that the claimed invention is 
generally a client-side validation program to check data entries to a form to ensure the 
data is of a correct type. In general, such form data validators were well known in the 
art at the time of the invention. Scholz teaches a client-side validator for data entry to a 
form. See generally, Scholz, paragraphs [0092]-[0175], teaching "Input Validation" to a 
form. Scholz does not use Applicant's terminology, but clearly teaches all functional 
elements specified by the Applicant. 

Regarding independent claim 1, as amended, Scholz teaches: 

A lightweight pattern validation system for a client device receiving markup 
defining a form, comprising: 

a validation processor separate from said markup and configured with a 
prototype interface for receiving both a field validation pattern and also form 
based input to be validated against said field validation pattern; and, 

a validation schpt library within said client device and packaging said 
validation processor, wherein 

the form has at least one form based input field programmed for validation 
using said validation processor. 
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(It is noted that the term "prototype" is read as merely non-functional descriptive ' 
language describing the interface as a working model. See, The American Heritage 
College Dictionary, Fourth Edition, Houghton Mifflin, 2002, definition of "prototype." 

See, Scholz, paragraph [0014], teaching that the code is within a validation 
processor receiving input from the form. The processor, residing on the client, is 
separate from the code in the form that receives the data and makes function calls to 
the processor. The processor receiving the function calls is separate from the input of 
the data. 

See generally, Scholz, paragraphs [0092]-[0175], teaching "Input Validation" to a 
form. Specifically, see, Scholz, paragraphs [0092]-[0013], teaching the overview of the 
validator.) 

Regarding dependent claim 2, as amended, Scholz teaches: 
The system of claim 1, further comprising: 

a library reference to said script library disposed in said markup; and, 
a function call to said validation processor further disposed in said 
markup, said function call having a configuration for passing a reference to a 
value in said at least one form based input field for validation in said validation 
processor. 

(It is noted that based on a review of the claims and the specification, the limitation of a 
"library reference to said script library disposed within markup" is read as a system, 
including computer code, within a markup language wherein entry to a form is validated 
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by the processor, and will be so read for the remainder of this Office Action. Further, 
claim 2 is read as limiting the function call to validate as passing the value by reference, 
and will be so read for the remainder of this Office Action. 

See, Scholz, paragraph [0109], teaching validation by reference to the validation 
code. And see, Scholz, paragraphs [0131]-[0132], teaching the custom tag library and 
the FormCollection object. See, Scholz, paragraph [0092], teaching the use of a 
markup language.) 

Regarding dependent claim 3, Scholz teaches: 

The system of claim 2, further comprising a plurality of additional function 
calls to said validation processor disposed in said markup, each additional one of 
said functional calls having a configuration for passing a reference to a value in a 
corresponding form based input field for validation in said validation processor. 
(It is noted that the limitation of "a plurality of additional function calls to said validation 
processor disposed in said markup" is read by the Examiner as merely repeating the 
passing by reference validation claimed in dependent claim 3, and will be so read for 
the remainder of this Office Action. 

See, Scholz, paragraph [0147], teaching multiple tags and, inherently, multiple 
function calls to those tags.) 



Application/Control Number: 10/712,544 



Art Unit: 2176 



Page 15 



Regarding dependent claim 4, Scholz teaches: 

The system of claim 2, further comprising a validation shell function 
encapsulating said function calL 
{See, Scholz, paragraph [0131], teaching the FormCollection library and functions calls 
contained therein.] 

Regarding dependent claim 5, Scholz teaches: 

The system of claim 3, further comprising a validation shell function 
encapsulating said function call. 
(See, Scholz, paragraph 0131, teaching the tag library containing the FormCollection of 
function calls.) 

Regarding independent claim 6, as amended, Scholz teaches: 
A pattern validation method comprising the steps of: 
retrieving a value for a form based input field from a form defined in 

markup rendered in a content browser; 

passing said retrieved value along with a validation pattern for said form 

based input field to a validation process disposed within a lightweight validation 

library separate from and coupled to said rendered markup; and, 

validating said retrieved value according to said validation pattern in said 

content browser. 
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(It is noted that the term "lightweight" is read as merely non-functional descriptive 
language and is not given weight as a patent limitation. 

See, Scholz, paragraph [01 16], teaching a "form processor" as a separate 
component or module. 

See, Scholz, paragraphs [0092]-[0175], teaching retrieving input, passing the 
input value, and validating the retrieved value according to a valuation pattern within the 
content browser. Specifically, see Scholz, paragraph [0092] teaching the validation with 
a markup language, HTML and/or XML, in a client-side valuation.) 

Regarding dependent claim 7, Scholz teaches: 

The method of claim 6, further comprising the step of repeating said 
retrieving, passing and validating steps for at least one additional value for at 
least one additional form based input field disposed in said markup rendered in 
said content browser. 

(It is noted that claim 7 is read by the Examiner as merely repeating the steps claimed 
in dependent claim 6, and will be so read for the remainder of this Office Action. 

See, Scholz, paragraph [0147], teaching multiple tags and, inherently, multiple 
function calls to those tags.) 
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Regarding dependent claim 8, Scholz teaches: 

The method of claim 6, further comprising the step of performing said 

retrieving, passing, and validating steps in a validation shell function disposed in 

said markup rendered in said content browser. 
(See, Scholz, paragraph [0092] teaching the validation with a markup language, HTML 
and/or XML, in a client-side valuation.) 

Regarding dependent claim 9, Scholz teaches: 

The method of claim 7, further comprising the step of performing said 

retrieving, passing, validating and repeating steps in a validation shell function 

disposed in said markup rendered in said content browser. 
(It is noted that the claim is read as merely repeating the interaction through the 
inherent interface to repeat the method steps specified in claim 7. 

See, Scholz, paragraph [0092] teaching the validation with a markup language, 
HTML and/or XML, in a client-side valuation.) 

Regarding independent claim 10, Scholz teaches: 

A pattern validation method comprising the steps of: 
defining a pattern validation routine to validate form based input provided 
through a prototype interface to said routine based upon a validation pattern also 
provided through said prototype interface; 
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packaging said pattern validation routine into a lightweight validation script 

library; 

referencing said lightweight validation script library in markup disposed 
within a content server configured to distribute said markup to requesting clients; 

defining at least one form based input field in said markup and further 
defining a validation pattern for each of said at least one form based input fields; 
and, 

for each form based input field and defined validation pattern, disposing a 
function call to said pattern validation routine in said lightweight script library. 
(See, Scholz, paragraphs [0092]-[0175], teaching retrieving input, passing the input 
value, and validating the retrieved value according to a valuation pattern within the 
content browser. Specifically, see Scholz, paragraph [0092] teaching the validation with 
a markup language, HTML and/or XML, in a client-side valuation. 

See also, Scholz, paragraph 0116, teaching the separate validating component 
or module. 

See also, Scholz, paragraph [0174], teaching that the code could alternatively be 
executed at a server. 

See also, Scholz, paragraphs [0131]-[0132], teaching a custom tag library and 
FormCollection object, with function calls.) 
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Regarding independent claim 11, as amended, Scholz teaches: 

A machine readable storage having stored thereon a computer program 
for pattern validation, the computer program comprising a routine set of 
instructions which when executed by the machine cause the machine to perform 
the steps of: 

retrieving a value for a form based input field from a form defined in 
markup rendered in a content browser; 

passing said retrieved value along with a validation pattern for said form 
based input field to a validation process disposed within a lightweight validation 
library separate from and coupled to said rendered markup; and, 

validating said retrieved value according to said validation pattern in said 
content browser. 

(Claim 1 1 incorporates substantially similar subject matter as claimed in claim 6, and, in 
further consideration of the following, is rejected along the same rationale. The 
Examiner takes official notice of the fact that that method steps that are performed by a 
compute are stored on computer or machine readable storage. It would have been 
obvious to one of ordinary skill in the art at the time of the invention to store the claimed 
method steps on computer readable storage for purposes of archiving, sale, 
transportation, etc.) 
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Regarding dependent claim 12, Scholz teaches: 

The machine readable storage of claim 11, further comprising the step of 
repeating said retrieving, passing and validating steps for at least one additional 
value for at least one additional form based input field disposed in said markup 
rendered in said content browser. 

(It is noted that the claim is read as merely repeating the method steps specified in 

claim 11. 

Claim 12 incorporates substantially similar subject matter as claimed in claim 7, 
and is rejected along the same rationale.) 

Regarding dependent claim 13, Scholz teaches: 

The machine readable storage of claim 11, further comprising the step of 
performing said retrieving, passing, and validating steps in a validation shell 
function disposed in said markup rendered in said content browser. 

(Claim 13 incorporates substantially similar subject matter as claimed in claim 8, and is 

rejected along the same rationale.) 

Regarding dependent claim 14, Scholz teaches: 

The machine readable storage of claim 12, further comprising the step of 
performing said retrieving, passing, validating and repeating steps in a validation 
shell function disposed in said markup rendered in said content browser. 
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(It is noted that the claim is read as merely repeating the method steps specified in 
claim 12. 

Claim 14 incorporates substantially similar subject matter as claimed in claim 9, 
and is rejected along the same rationale.) 

Regarding dependent claim 15, Scholz teaches: 

The system of claim 1, wherein the client device is a pervasive device. 
(Claim 15 incorporates substantially similar subject matter as claimed in claim 1 and, in 
further view of the following is rejected along the same rationale. It is noted that the 
term "pervasive device" is not defined in the specification. The Examiner consulted 
"IEEE 100, The Authoritative Dictionary of IEEE Standards Terms," Seventh Edition, 
IEEE Press, 2000, and "Microsoft Computer Dictionary," fifth edition, Microsoft Press, 
2002, and the term was not found. The Examiner believes the term to have been 
intended by the Applicant to mean that the device is permanent, such as a permanent 
client device. See, Claim 15. See also, "American Heritage College Dictionary, fourth 
edition, Houghton Mifflin Co., 2002, definition of "pervasive." The term will be so 
defined for the remainder of this Office Action. It is noted that the term "pervasive" as 
applied to a client device, is read as non-functional descriptive language. It was known 
to one of ordinary skill in the art at the time of the invention that any device connected to 
a server as a client is permanent while connected to the server. Upon disconnection, 
the device is no longer a client device, it is merely a stand-alone device. Therefore, the 
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term "pervasive" is read as non-functional descriptive language that does not constitute 
a patentable distinction over the prior art.) 

15. It is noted that any citations to specific, pages, columns, lines, or figures in the 
prior art references and any interpretation of the references should not be considered to 
be limiting in any way. A reference is relevant for all it contains and may be relied upon 
for all that it would have reasonably suggested to one having ordinary skill in the art. 
See, MPEP2123. 

Response to Arguments 

Applicants' arguments filed August 30, 2006 have been fully considered, but they 
are not persuasive. 

Regarding rejections of claims 1-14: 

Applicant argues that the Examiner in the Final Office Action, filed May 31, 2006, 
[hereinafter "Final Office Action"] "failed to clearly designate the teachings in Scholz 
being relied upon the statement of the rejection as required by 37 C.F.R. § 1.104(c)." 
Applicant presents no further argument, but only "incorporates herein all the prior 
arguments previously presented." See, Remarks, pages 6-7. 

The Examiner disagrees. 

The Examiner states that the grounds of rejection in the Final Office Action were 
clearly explained and adequate citations were made to the references in the rejections 
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Regarding rejection of claim 1-14: 

Applicant argues that the rejection and response to argument in the Final Office 
Action, failed to respond to Applicant's arguments. See, Remarks, pages 8-1 1 . 

It is noted that independent claims 1, 6, and 11 have been amended. Arguments 
whether the prior claims were responded to appropriately in prior actions are now moot. 

Regarding rejections of claims 1 and 10: 

FIRST: Applicant argues that the Examiner's interpretation of the term 
"validation script library" in the Final Office Action was in error. See, Remarks, pages 7- 
8. Specifically, Applicant argues that the interpretation of the terms as a "client side 
input validator" is without evidentiary basis. 

The Examiner disagrees. 

In the Final Office Action, the Examiner noted: "The term 'validation script library' 
is defined in the specification by its use only, which is read by the Examiner, based on a 
review of the claims and specification, as a client side input validator . . .." See, Final 
Office Action, page 3, emphasis added. 

The specification defines a "validation script library" in the following contexts: 
a) "The system further can include a validation script library packaging the 
validation process ." See, disclosure, paragraph [0008], emphasis added. This is the 
evidence that the term, in its broadest reasonable interpretation, was a "validator." 
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b) "Moreover, as the validation processor 150 can be packaged within a 
lightweight validation script library 140, there will be no need to cache a complete copy 
of a conventional script library thus permitting the lightweight validation script library 140 
to remain resident in the client computing device 130 -- even where the resources of the 
client computing device 130 are limited." See, disclosure, paragraph [0019], emphasis 
added. This is the evidence that the term, in its broadest reasonable interpretation, was 
a "client side" device. See also, figure 1, showing the "lightweight validation script 
library" 140 residing on the client device 130. 

c) See, figures 1-3, showing the validation process as part of the input. 
Particularly see, figure 3, element 330, as the step to "pass input data to validation 
shell." This is the evidence that the "validation script library received input. 

Therefore, in its broadest reasonable interpretation, the term "validation script 
library" may reasonably be interpreted as a "client side input validator." 

SECOND: Applicant further argues: "the term 'validation script library' implies 
that the validation script is located within a 'library'." See, Remarks, pages 7-8. 

The Examiner disagrees. 

The term "validation script library" implies that the validation script is a library, not 
that it resides within one. There is not support found in the original claims or 
specification that a "validation script" is separate from the "library." 

THIRD: Applicant argues that the Examiner " improperly broadens the scope of 
the claimed term beyond the reasonable broadest interpretation of the term by one 
having ordinary skill in the art." Applicant further argues: "By analogy, the Examiner's 
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analysis would interpret the phrase 'a computer disposed within a library,' which 
happens to be within a building, to mean 'a computer is disposed within the building." 
See, Remarks, page 8, emphasis in the original. 
The Examiner disagrees. 

Claim 1 clearly recites: "a validation script library within said client device and 
packaging said validation processor" which describes a validator residing in a client 
device. 

Claim 6 clearly recites: "passing said retrieved value along with a validation 
pattern for said form based input field to a validation process disposed within a 
lightweight validation library," which is the validation process within the validation library 
that receives input. 

In response to Applicant's argument by analogy: The claim limitations are not to 
a computer in a library in a building, but rather to a validator within the computer. It is 
clearly stated in claims 1 and 6 that the validator is located within the client device, 
therefore the building analogy is unnecessary. 

Regarding rejection of claim 2: 

Applicant argues that the Examiner's interpretation of the term "disposed within 
markup" means that "the invention used a markup computer language" is in error. 
Applicant further argues that "the Examiner has improperly failed to recognize that the 
term 'dispose within markup' establishes a relationship between a library reference and 
markup such that 'a library reference ... [is] disposed within markup,' as recited in claim 
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2." See, Remarks, page 8. 

The Examiner disagrees. 

The term "disposed within markup" was not known to have a definition known to 
one of ordinary skill in the art at the time of the invention to the knowledge of the 
Examiner. The Examiner consulted "IEEE 100, The Authoritative Dictionary of IEEE 
Standards Terms," Seventh Edition, IEEE Press, 2000, and "Microsoft Computer 
Dictionary," fifth edition, Microsoft Press, 2002, and Newton, "Newton's Telecom 
Dictionary," 18 th edition, CMP Books, 2002, and the phrase was not found. The term 
"disposed" was known by one of ordinary skill in the art at the time of the invention in its 
non-technical meaning as "to place or set in a particular order." See, "The American 
Heritage College Dictionary," fourth edition, Houghton Mifflin Co., 2002, definition of 
"dispose." In context, to place input data in a certain order, that order being in a markup 
language, is a reasonable interpretation of the phrase. 

Upon examination of the context within which the term was used in the 
specification, there is no guidance. 

In Applicant's discussion in the specification of the related art, the term "markup" 
is used within the definition known to one of ordinary skill in the art at the time of the 
invention, namely that of a markup language. As discussed in the specification, in 
context, the term was used as follows: "Within the context of hypertext markup 
language (HTML) documents, it is well known to incorporate pattern validation within the 
interface." See, disclosure, paragraph [0005]. See also, paragraphs [0004]-[0007] also 
discussing other markup languages used in form validation. Significantly, nowhere in 
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the specification is the phrase "disposed within markup" defined or differentiated from a 
markup language. 

Applicant states without reference or further explanation that the term "disposed 
within markup" establishes a relationship between a library reference and markup such 
that a library reference is disposed within markup. This is merely a circuitous statement 
without foundation in the specification. Finally, there is no definition or differentiation of 
"markup" found in Applicant's argument that would distinguish the term over the 
customary and ordinary usage of the term, known to one of ordinary skill in the art at the 
time of the invention, as identifying a markup language. 

Therefore, in its broadest reasonable interpretation, the term "disposed within 
markup" is read as being written in a markup language. 

Regarding rejection of claims 1, 6, 10, and 11: 

Applicant argues that "Scholz fails to teach "the validation processor separate 
from said markup." Applicant further argues that Scholz teaches the opposite of the 
limitation of a processor separate from a markup. See, Remarks, pages 9-1 1 . 

The Examiner disagrees. 

Initially, it is noted that the term "markup" is not defined in the specification, as 
noted in several rejections above. The broadest reasonable interpretation is that 
"markup" means some form of markup language. 

Scholz clearly teaches that a validation processor may be separate from the form 
or its markup language expression. See, Scholz, paragraph [0014], teaching that the 
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code is within a validation processor receiving input from the form. The processor, 
residing on the client, is separate from the code in the form that receives the data and 
processed on the processor. The processor receiving the function calls to process the 
data is separate from the input of the data on the form. 



Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Michael K. Botts whose telephone number is 571-272- 
5533. The examiner can normally be reached on Monday through Friday 8:00-4:00 
EST. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Heather Herndon can be reached on 571-272-4136. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 
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